Or more specifically, how .NET attacks are not so hidden from us.
So, just a minor introduction about myself.
I'm a threat hunter at Countercept, F-Secure company, whereby we are a consultancy firm.
I am in the detection and response team.
So, my job is literally detection and response.
For the detection part, I do something known as hypothesis-driven threat hunting,
whereby I look through all my client data.
In the events where I find something suspicious, I respond to it.
I investigate them, such as using process logs, event logs, MFT.
So, you could think of it more like real-time incident response.
I do quite a bit of attack detection research as well.
So, part of me being a defensive security person, I constantly need to make sure that I'm on par with the offensive guys.
And that's where I do some form of attack detection research.
And if it's interesting and big enough, I blog about them.
So, you could find some of my blog posts on the Countercept website, actually.
I am sort of a little code junkie as well.
I like to automate stuff.
I like to write scripts to automate some of my daily works.
And it helped me a lot with my job as well, as I need to filter out lots of data at times.
And lastly, I'm a Netflix edit.
I like to just relax in my home and sit down and just watch TV.
So, yeah, just four things about myself.
And let's move on to the agenda, which is why we are here.
So, why are we here today?
Firstly, I'm going to discuss the importance of downlight detection.
Why do we actually need to do it?
And how do we actually do the detection itself?
So, I'm just going to start off with why the importance of downlight detection.
So, as a chat hunter myself, I have faced quite a bit of chat actors and adversaries.
And I have seen my fair share of investigation.
And some of these attacks, most of these chat actors, what they like to use is something known as script-based attack.
Whereby they are typically run in processors that are commonly installed on a Windows Enterprise machine,
such as PowerShell, where I've seen PowerShell invoking a download string against a C2 channel,
invoking Mimikatz, VBScript, enumerating user drive,
or even those pescalated macros that you see attempting to trick people into clicking them to get a free iPhone.
And out of all these attacks, PowerShell is a hot favorite, I realize.
Well, probably because it's really powerful.
You could do quite a bit of activities with PowerShell, such as loading shellcode into memory,
calling upon the .NET API, which is basically what PowerShell is based on,
and even calling upon the Windows native API.
And if you think about it, it's quite easy to actually POC something with PowerShell.
All you need to do is pop up a console and test your code there.
And if you just pop up a search engine, do a quick search on PowerShell frameworks,
you can probably get a lot of hits from GitHub that gives a wide variety of PowerShell.
But as defenders, we are also getting better.
As compared to in the past, it's not that hard to detect bad PowerShell anymore.
With the rise of EDR agents, we can actually analyze parent-child process relationship,
and this gives us a spread of visibility on enormous PowerShell execution.
For example here, we see Microsoft Word or Excel spreadsheet spawning a PowerShell process.
And that is quite anonymous, because you would not expect a Word document
or an Excel spreadsheet to spawn a PowerShell process.
I mean, those are mainly for, like, working stuff, editing your spreadsheets and all.
Although, to be frank, I've seen legitimate instances of this in my clinic state, but it's very rare.
So you expect something like this to be rather anonymous and probably malicious.
We can also see the common line arguments tagged to a newly spawned PowerShell process,
such as here, we can actually see what the PowerShell code was doing.
In this case, what the PowerShell code was doing was simply printing out an evil command.
So, nothing too malicious.
But from here, I hope that you guys can actually understand that with this level of visibility,
as defenders ourselves, we are able to determine whether a bad PowerShell is actually being run.
And there are other defenses as well, such as MZ, which can assist antivirus with script-based attack detection.
So, take for example with this image here I have, where I enter MZ tools into the console.
The antivirus actually stops and blocks it.
So, this occurs because MZ acts as an interface.
When a command is entered to the PowerShell console, MZ will act as an interface which will send the command to the antivirus for scanning.
If a signature has been created, the antivirus will then stop the command from being executed.
There are other defenses as well, such as PowerShell script-based logging, whereby for PowerShell version 5 and above,
the process would be logged into the event logs.
And this gives another visibility for defenders to actually leverage on.
So, all in all, I guess as an industry as a whole, defenses have improved.
We are given more opportunities to detect bad PowerShell.
And the adversaries, the bad guys, they are aware of it.
They know that PowerShell is not as easy as it was in the past.
And some of them have migrated different tooling and techniques, such as .NET.
Whereby you invoke the .NET core instead of choosing something like PowerShell, for example.
And why .NET, though?
If you think about it, it's very similar to PowerShell.
You have powerful functions.
It's installed by default on Windows machine.
But with one key difference.
There is currently a lack of telemetry regarding towards .NET.
So, I'm just going to do a quick demonstration here.
Whereby I'm going to compare a PowerShell and a .NET.
Both of them are going to do exactly the same thing.
Firstly, they're going to write a registry key through the use of a .NET API.
Secondly, they're going to pop a message box with the use of a Windows native API.
So, native API is essentially a Windows library.
Whereby we are actually importing functions from Windows library such as user32.dll, kernel32.dll.
So, I have a demonstration here. We shall start.
So, right here I have two HTA scripts file.
A PowerShell HTA file and a .NET HTA file.
Both of them will run within the MSHTA process.
So, let's click on the PowerShell process first.
So, I'm going to click on the button to execute my PowerShell code.
And as you see, I pop a message box from kernel32.
And I actually return a registry key as well.
So, we're going to look at the indicator.
The indicators related to this attack now.
So, we are going to look at the process logs.
And from here, we can actually see a PowerShell process being spawned.
And it was being created from a parent process which is mshj.exe.
So, this is quite suspicious by itself.
And furthermore, we can actually look at the common arguments here.
So, we have this bunch of encoded base64 PowerShell code.
Which I'm going to decode in front of you now.
So, I'm just going to base64 decode it.
And from here, we can actually see the entire PowerShell code that was being run.
So, as a defender myself, now I know what is being executed on this stack state.
And I know how to remediate against it.
So, let's delete all my artifacts now.
And we're going to demonstrate the .NET HTA file.
I'm going to show you the level of visibility we have on .NET HTA currently.
And why is it harder as compared to PowerShell.
So, same thing. I'm going to execute the .NET code directly.
And now, I pop a message box.
I've written a registry key.
And if you look at my process log now.
There is only one indicator.
Which is an MSH TA process running a HTA file.
And with that, we don't really have a lot of visibility on how to further investigate such a problem.
So, just a quick summary of what I actually did.
Firstly, for the PowerShell process.
I used the MSH process to spawn a PowerShell code process.
Which, thereafter, called upon the PowerShell code to write a registry key and pop a message box.
For the .NET portion, I did the same thing.
I used a MSH process to call upon the .NET code directly to perform exactly the same task.
And here's the question though.
How did I actually achieve this?
Because an MSH HTA process
typically is not able to actually invoke the .NET library.
So, I achieved this with something known as an in-memory assembly loading.
Whereby, firstly, on the victim's machine, I will compile a C-sharp code into a .NET assembly.
I will then serialize it and embed it within a delivery mechanism.
In my case, I used a HTA delivery mechanism.
But technically, you could use any delivery mechanism.
With that, I will deliver my payload to the attacker's machine and load it into the victim's machine memory.
And once it's in the victim's machine memory, I will deserialize it back to the .NET assembly.
And once it's deserialized, I will use reflection to actually reference this assembly and create an instance out of it.
So, this entire flowchart, basically, what is it trying to replicate is something like this.
For those of you who are aware of object-oriented programming,
you realize that this entire flowchart is attempting to replicate this behavior.
Whereby, you're attempting to reference an assembly.
And with the reference assembly, you invoke the class constructor to create an object.
And with that object, you can call its method.
And what can this loaded object do?
Basically, anything that PowerShell can do, it can do.
So, just to give a midpoint check summary of what we have discussed,
if we run a C-sharp object through the use of in-memory assembly loading,
this object is capable of doing anything that PowerShell can do with one key difference.
There's currently a lack of telemetry to detect it.
And here's our challenge today.
Can we actually detect this?
And that is where I'm going to talk about now, the actual detection portion of .NET attacks.
So, first, I'm going to do some form of initial triage, initial investigation with Process Hacker.
Process Hacker is a tool which allows you to analyze the process behavior.
You can look at the process threads, the module it loads, the string that it has.
And I'm going to use it to analyze the MSHA process, which was responsible for running the .NET code.
So, right here, we see something interesting here.
For the MSHA process, we actually see some interesting module loads here.
Which are actually module loads related to the .NET runtime engine DLL.
And this is quite interesting.
And this is quite interesting because MSHA actually requires this engine to execute the .NET assembly code.
But it's also very dodgy, if you think about it, very suspicious.
Why would MSHA require such a .NET runtime DLL engine when typically it only runs HTML or JavaScript code?
So, this analogy can be hold true for other binary as well.
You will not expect Microsoft Word, Microsoft PowerPoint to execute .NET code.
So, such runtime engine DLLs should not actually be within this process.
So, with this, we can actually think of an interesting hypothesis to hunt.
Whereby, for example, we can hunt for processes that typically do not execute .NET code.
And hunt to see whether these binaries contain a runtime engine DLL.
But unfortunately, this hypothesis is not perfect.
What if a binary that was related to .NET was used?
Such as msbuild.exe, which is an application that is used to build .NET applications.
Or perhaps a third-party application such as SQL Server, in which it allows a user to run C-sharp code on it.
So, if you think about applications like this, it's not uncommon for them to actually have a .NET runtime DLL being loaded into it.
So, we're going to need something better than this.
And fortunately for us, the answer actually lies deep within Process Hacker.
Within Process Hacker, there is a section that only appears when it detects events related to assembly load.
And these assembly loads have to be .NET assembly loads.
And what's interesting about this section here is that you can actually detect any event related to a .NET assembly load.
And if you look closely at one of the assembly loads, one of them is without a path as compared to the other three.
So, lack of a path potentially indicates some form of in-memory assembly loading.
Which is what I was trying to do in my previous flowchart, whereby I was trying to load an assembly through the use of in-memory.
And one question is, how did Process Hacker actually achieve this?
We realized that deep within Process Hacker code, they actually leverage on a set of ETW providers.
And right here in front of us, there is a great wealth of information that we can potentially leverage on.
And with this information, we at Countercept, we wrote up a Python proof-of-concept code to consume these .NET ETW events with the help of FireEye's ETW tracing library.
So, with this information, let's try to detect the attack that I did in my demonstration earlier.
Let's try to find indicators related to in-memory assembly load, which we saw covered earlier with Process Hacker.
Let's try to find indicators related to registry creation through the use of .NET API.
And finally, let's try to find indicators related to the invoking of native API.
So, let's continue our discussion on in-memory assembly loads.
Firstly, with Process Hacker, we're actually able to use events related to the loading of .NET assembly to flag out such various events.
There's another event we can use, and this is something known as the JIT compiler, just-in-time compilation.
So, before I dive deep into just-in-time compilation, we need to first understand the .NET code compilation architecture.
A .NET code is essentially a managed code whereby they run within a virtualized environment.
With something known as the Common Language Runtime.
So, a .NET code doesn't compile directly to native code.
What happens is, when a .NET code compiles, it compiles to something known as the Common Intermediate Language, within the CLR.
And when it's going to be executed, basically when you double-click it, it will go to something known as the JIT compilation, which will compile this to the Windows native code.
Once the code has been compiled to a native code, it will be cached.
And the JIT compiler will not be used.
And this is interesting to us because when the JIT compiler is used, an event will be generated.
Which means that an event will be generated whenever a .NET method is first utilized.
Subsequently, it will not be generated because the code will have been cached.
So, with this, we actually have two events that we can use to detect in-memory assembly load indicators.
Firstly, the event related to the loading of .NET assembly.
As well as event related to JIT compilation.
So, what I have here is an output snippet from my Python POC code.
So, firstly, we can detect the loading of my assembly without a path.
And that is through the events of assembly load.
And secondly, we can actually attempt to trace what the assembly was doing.
In this case, we see that the assembly was trying to call upon the constructor class.
And if you look back at what I was trying to achieve previously with my flowchart,
I was actually trying to reference an assembly and load an instance out of it.
So, to sum it up, we actually are able to detect indicators related to in-memory assembly loads.
So now, let's look at another indicator.
We're going to look at indicators for .NET API related to the registry creation.
So, we used JIT compilation was quite useful for us previously.
So, can we use this?
Unfortunately, we can't because JIT compilation doesn't occur for native .NET assembly.
And what I mean by native .NET assembly?
I mean libraries like system.txt whereby as a C-sharp programmer,
you'll reference system.txt to allow you to call upon the console.WriteLine function
to print out statements to the, to output out statements to the console.
And this happens because when a .NET framework is installed,
the .NET, native .NET assemblies are installed as well.
And once they're installed, they'll actually be compiled to native code and cached
by something known as the native image generator, NGEN.
So, essentially, it compiles the .NET assembly to native images and it will cache them.
And because of this, because they are cached, JIT compilation will not occur.
And because of that, we are not really able to actually detect indicators related to
the use of native .NET APIs for registry creation.
So, let's move on to our final indicator.
Indicators related to the invoking of native API.
So, we can use an ETLV event known as InteropEvents to help us with this.
So, these are essentially events generated whenever a .NET assembly makes a call towards the Windows native API.
And this is an example of a native code.
As you have seen earlier from my message box, it was actually a native function that I imported from the User32 DLL library.
And with that, we're actually able to detect an event towards it,
whereby you're able to see my assembly call invoking the message box.
So, native API is very useful.
Like, you could use it to do a lot of interesting activities such as you could use a native API to send an outbound network connection.
But, track actors can also abuse this.
Track actors can use it to do key logging.
They can use it to extract credentials from memory and any other malicious activities that you can think of.
So, us having visibility on this is really useful as well.
So, to sum it up, we're actually able to detect two out of three.
So, pretty good, I would say.
Now, let's use what we have learned on an actual demonstration.
We're going to demonstrate our indicators on a real-world example, Silent Trinity.
So, Silent Trinity is a post-exploitation framework which is coded in Ion Python.
So, Ion Python is essentially Python that is tightly coupled towards the .NET library.
And with that, we're going to do two things.
We're going to launch a .NET assembly,
which will be responsible for launching
all the other assemblies, like all the Silent Trinity assemblies.
And we're going to launch Safety Cats.
We're going to do something malicious now.
We're going to launch Safety Cats, a credential extraction tool.
So, on my right, right here is a console which basically holds my stager,
my Silent Trinity stager.
It's an XML file which will be built by msbuild.exe.
And on the left here,
is my Python POT script that is mainly used for the event tracing.
So, I'm going to execute the Python script first
before executing the Silent Trinity stager.
So, I've executed the Python script,
and now I'm going to execute the Silent Trinity.
As you can see, there's a whole bunch of output coming out now,
because these are ATW events.
There's a whole lot of information.
So, we're going to ignore all this information for now,
and we're going to move towards my attacker's machine,
which is right here.
And I'm going to run Safety Cats.
I'm going to extract user credentials from my victim's machine.
As you can see here, I grab out a bunch of user credentials.
And now, let's move back to our victim's machine.
And as you can see, we're still getting so much output here.
And frankly, most of them aren't probably going to be very useful.
So, I'm going to ignore this, and I'm going to minimize it.
So, I've actually filtered out a bunch of necessary information for us to look at.
And that is what you expect to do in the real world.
In the real world, your base Windows telemetries are a whole bunch of data,
and as defenders ourselves,
we have to know how to filter the necessary data for us to look at.
So, firstly, what I have right here is a bunch of assembly loading.
of IMPython assemblies.
And as you can see here, there is no path tag towards it,
which is quite suspicious.
IMPython by itself is not malicious,
but it loading with a path is very anonymous,
and most organizations typically will not execute IMPython on their state.
So, having visibility of this will definitely give some form of anonymous activity.
So, other than the in-memory assembly loads,
we're going to see what it was actually doing.
So, as you can see below here,
several interesting native API calls were actually made,
such as load library, virtual-alloc, get-proc-address.
So, probably legitimate stuff,
but there are actually activities that can be used to do code injection as well.
And there's one more native API that is quite interesting,
which will be more specific to what we're actually looking at.
And it's something known as the mini-write-dump,
which I will show you now.
So, for extracting credentials from memory,
typically you would target a process such as lsess,
and you would dump its contents out.
Mini-dump-write allows a user to grab a handle towards a process,
and dump its contents to a file.
And that is essentially what is happening here.
So, having all this visibility actually helped us in trying to determine
whether a bad .NET code was being run.
So, just to sum up,
all the telemetry that I have discussed.
Firstly, .NET Runtime DL.
So, basically, we can hunt for binaries that do not execute .NET code,
and we see that this binary contains a .NET Runtime DL,
there is something suspicious that we can potentially leverage on.
We can also look at .NET ETW events,
and with ETW events, it's a wealth of information for us to look through
to actually determine whether or not
what the .NET code was attempting to run.
And we have other telemetries as well.
If we base on a cyber queue chain,
you expect a .NET code to occur at the execution phase,
and typically you can argue that a .NET code could be executed
at the persistent phase, the control phase,
but all these leave different indicators.
At the persistent phase,
you can hunt for registry locations, scheduled tasks.
At the control channel,
an attacker can use a .NET code to communicate with the C2 channel,
but that will leave network indicators.
You could find, within a day,
how many outbound connections towards a particular IP address,
and how about before even the .NET code was being executed?
How was it even delivered?
What are the delivery mechanisms used to actually deliver it?
We can hunt for such behavior,
and with all these indicators put together,
we actually paint a whole complete picture on how to detect a bad .NET code,
which allows us to determine what actually happened.
So, having a robust detection strategy like this
aids us in trying to actually determine,
in trying to detect bad track actors.
So, I guess to wrap it up on what I've discussed,
PowerShell is still a very good weapon of choice for track actors,
but defenders have gotten better at detecting them.
There are more opportunities to detect bad PowerShell code,
so,
as compared to what it was in the past,
it's not as hard as it was before.
And, attackers being attackers,
they're always moving to different techniques and tooling,
and one of them is .NET attacks.
But, as I have shown here,
.NET attacks aren't that invincible themselves.
We can actually detect them.
And lastly, more importantly,
is to try all this yourself.
All the things that I've demonstrated here,
they are all open source.
The Python POC code that I was demonstrating earlier,
you can actually find it on countless sites,
such as Github.
Silent Trinity, you can also find on Github.
Process Hacker is also an open source tool.
So, I guess this marks the end of my presentation.
So, any questions?
Okay.
All right, then.
Thank you.
Oh, wait, is there a question?
All right.
I'm sorry.
All right.
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Thanks for watching!
